Systems and methods for online, real-time, social gaming

ABSTRACT

Systems and methods for designing a social gaming platform in which participants compete to determine who best predicts the outcomes of conditions relating to activities at sporting events, TV shows, or other types of events. In a game, players compete with other players in the same group or in different groups via a gaming platform that employs a live digitized information feed from a contemporaneous event (while an event is currently in-progress) in addition to historical information relating to the event available from third party sources. Such information allow players (and also the system) to predict outcomes of conditions relating to activities at events, wherein such conditions are either user-contemplated, pre-stored in the system, or generated live (by the system or users). Additionally, embodiments of the present system utilize geo-location information to enable creation of user-groups based on the physical location of system users and social network affiliation of users.

CROSS-REFERENCE TO RELATED APPLICATION

This application claims benefit under 35 U.S.C. §119(e) of U.S. Provisional Patent Application No. 61/418,590, filed Dec. 1, 2010, and entitled “Systems and Methods for Online, Real-time, Social Gaming”, which is incorporated herein by reference as if set forth herein in its entirety.

TECHNICAL FIELD

The present systems and methods relate generally to online, real-time social gaming, and more particularly to systems and methods involved in the design of a mobile and web-based social gaming platform for players to interact and play online games, wherein aspects of the online game are determined by live digitized data feeds from happenings at contemporaneous events (while events are currently in progress) in addition to historical data gathered from such types of events. The disclosed systems and methods allow user interactions in real-time or almost real-time including the ability to pose questions, predict outcomes, answer questions, and perform other activities relating to sports events, TV shows, political debates, or any event that is capable of providing a digitized data feed of the happenings at the event, wherein such a feed is typically available from third party sources.

BACKGROUND

Most persons interested in entertaining events such as sports and current affairs prefer to play online games with other persons who also have similar interests via a mobile and/or a web-based online gaming platform to get involved, be social, be competitive, and for added excitement while watching sports or a current affairs event. Examples of such events include, but are not limited to sporting events like NFL, football, NCAA football, basketball, baseball, etc. and/or current events such as The Academy Awards, reality TV shows, political debates, etc. A common feature of such online games is for participants to predict outcomes of certain conditions or characteristics of the event. For example, for an avid football fan, such a condition can be “who will score more points in the first half”, or “how many three-pointers will the winning team have”, and various others. Typically, persons who play or participate in the online game (players) predict the outcome of such conditions apriori, i.e., before the actual occurrence of the outcome. The player with the most correct number of outcomes usually wins.

In many scenarios, to add a new level of excitement, online gaming platforms creates pools (groups) of players by matching users with similar background, affiliations or interests so that they can be a part of the same pool. Sometimes, users of the gaming platform can create their own pools and invite other users (or even, non-users of the gaming platform) to join one or more user-created pools. Subsequently, players in the same pool can compete with each other, or even, players from different pools can also choose to compete with each other in predicting outcomes of certain conditions or characteristics of the event. As will be understood by one of ordinary skill in the art, pools can be set up for a specific event, game, a series, or an entire season, and can further be customized (depending on the underlying technology of the gaming platform) according to players' preferences.

However, conventional systems do not enable participants in an online game to have access to a data teed of the happenings at the event in real-time. The data feed can be used in the form of analytics for helping in predicting outcomes of certain conditions, in one manifestation this could mean users (players) providing answers to questions as a part of an online social game, wherein users have the option to play in inter- or intra-pool games. Questions that are presented in a pool, in one instance, can be either selected from a pre-existing set of questions available via a gaming platform, or in another instance, pool creators have the ability to generate custom questions (e.g., in sporting events, “will Team X score on this drive?”) while an event is unfolding in real-time. These questions are likely to be distributed to the appropriate participants via email, mobile push notifications, mobile text alerts, MMS by the gaming platform while an event is in-process. Participants of pools can then respond via mobile or web back to the gaming platform that then scores these questions, adjusts pool scoring and displays rankings of users in near-real time. As will be understood and appreciated, gaming platforms constructed using the above-mentioned elements will create unprecedented levels of user-engagement and excitement.

Again, most traditional online gaming platforms do not provide real-time sporting and event data feeds. Even further, historical data relating to sports events (e.g., from past seasons, or tournaments), or other any other form of historical event-related data are not provided to users of online gaming platforms. Moreover, most online gaming platforms are not technologically sophisticated because they lack statistical decision making tools that are usually helpful in most online games, e.g., they lack the ability of predictive outcome modeling of certain conditions or characteristics of events. Additionally, they are also not easily customizable to according to players' preferences.

Therefore, there is a long-felt but unresolved need for a system or method for designing a social gaming platform that solves the aforementioned problems. Aspects of the present disclosure are aimed at solving the aforementioned problems and provide a unique social gaming and networking experience to users (players/participants) of the system. The disclosed system is highly interactive and easily configurable by users having minimal technical skills, and easily operable by system administrators. Further, the system is easily accessible online by a plurality of users' electronic devices, either via a website, or mobile application programs running on users' mobile devices so that users can play along while an event is happening (in-process). Users (players) of the system have access to analytics extracted from live event data feed, and also (previous) historical event-related data. Even further, aspects of the present system are responsive to users' current geographical location and allows users located in the same vicinity (e.g., at a venue, at a bar, at a stadium, at the event, etc.) to play with each other seamlessly in real-time.

BRIEF SUMMARY OF THE DISCLOSURE

Briefly described, and according to one embodiment, aspects of the present disclosure generally relate to systems and methods for designing a social gaming platform that allows users to create online games in which participants compete to predicts the outcomes of specific conditions relating to activities at sporting events, TV award shows, or other types of events. For example, in one aspect and as will be understood from the discussions that follow, conditions can be in the form of multiple-choice questions, free-form questions that have answers comprising a few lines, tournament brackets, and the like. Therefore, in such examples, a game involves participants (OGS users) predicting the answers of questions. In an exemplary aspect, questions (or, more generally, conditions) comprise real-time in-event questions created by the OGS or by system users, or even, pre-stored in the system.

According to one aspect and described in greater detail herein, an Online Gaming System (OGS) receives digitized live event data feed from on or more third party sources. Additionally, the OGS also stores historical information relating to an event (e.g., sporting events, TV award shows, etc.), or generally, accesses historical information relating to an event from third party sources. It will be understood that such live-feed and historical information are presented to players (participants) as analytics for their guidance in predicting the outcomes of specific conditions relating to the activities at the event. and extracts analytics from such data feed. Such analytics are then utilized by the OGS to computationally generate answers (a\k\a a closes proximate answer) to the questions.

Typically, in an online game (also referred to as an OGS game, or even simply, a game) players compete with other players in the same (user group) pool or different pools, wherein the pools can be created by the OGS or by system users. According to another aspect, the OGS evaluates the answers predicted by game participants against computationally generated answers to the questions, the results of such evaluation being used to rank participants in an OGS game.

These and other aspects, features, and benefits of the claimed invention(s) will become apparent from the following detailed written description of the preferred embodiments and aspects taken in conjunction with the following drawings, although variations and modifications thereto may be effected without departing from the spirit and scope of the novel concepts of the disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings illustrate one or more embodiments and/or aspects of the disclosure and, together with the written description, serve to explain the principles of the disclosure. Wherever possible, the same reference numbers are used throughout the drawings to refer to the same or like elements of an embodiment, and wherein:

FIG. 1 is a high-level overview of an embodiment of the disclosed online gaming system (OGS) in an exemplary operating environment.

FIG. 1A shows an exemplary OGS architecture comprising various software modules, engines, data tables and other similar elements, according to one embodiment of the present system.

FIG. 2 shows an exemplary OGS architecture comprising various software modules, engines, data tables, and other similar elements, according to another embodiment of the present system.

FIG. 2A shows exemplary records stored in a profile data table comprising profile information of system users, according to one embodiment of the present system.

FIG. 2B shows exemplary records stored in a score data table comprising information relating to participants (and their responses) in various online games played by system users, according to one embodiment of the present system.

FIG. 2C shows exemplary records stored in a pool data table comprising information relating to user-created or system-created groups (pools) of participants, according to one embodiment of the present system.

FIG. 2D shows exemplary records stored in a statistics data table comprising information relating to user-created or system-created groups (pools) of participants, according to one embodiment of the present system.

FIG. 2E shows exemplary records stored in a content data table comprising miscellaneous information, according to one embodiment of the present system.

FIG. 3 is a flowchart that outlines an exemplary embodiment of the steps to create a profile/become a member.

FIG. 3A is a flowchart that outlines an exemplary embodiment of the steps involved in validating user credentials.

FIG. 4 is a flowchart that outlines an exemplary embodiment of the steps for creating a user-created group (pool).

FIG. 5 is a flowchart that outlines an exemplary embodiment of the steps for joining a user-created group (pool) via an OGS user interface.

FIG. 5A is a flowchart that outlines an exemplary embodiment of the steps for joining a pool from an email invite link transmitted by the OGS to potential system users.

FIG. 6 is a flowchart that outlines an exemplary embodiment of the OGS steps involved prior to the start of an event (e.g., a game).

FIG. 6A is a flowchart that outlines an exemplary embodiment of the OGS steps involved while an event (e.g., a game) is in-process.

FIG. 7 is a flowchart that outlines an exemplary embodiment of the processing steps in an embodiment of the OGS.

FIG. 8 is an exemplary embodiment of a summary table displaying characteristics/roles of various users of the system.

FIG. 8A is an exemplary embodiment of a summary chart of the population and personas that may play the game.

FIG. 9 is an exemplary embodiment of the flowchart that outlines a venue pool workflow.

FIG. 10A illustrates an exemplary screenshot of the user web interface for the OGS dashboard as seen by the user upon login.

FIG. 10B illustrates an exemplary screenshot of the user web interface for viewing and managing user pools.

FIG. 10C illustrates an exemplary screenshot of the user web interface for answering pool questions.

FIG. 10D illustrates an exemplary screenshot of the user web interface that provides the functionality of playing a game while a sporting event is in-process.

FIG. 11A illustrates an exemplary screenshot of the user mobile interface for the OGS dashboard as seen by the user upon login.

FIG. 11B illustrates an exemplary screenshot of the user mobile interface for viewing and managing user pools.

FIG. 11C illustrates an exemplary screenshot of the user mobile interface for answering pool questions.

FIG. 11D illustrates an exemplary screenshot of the user web interface that provides the functionality of playing a game while a sporting event is in-process.

FIG. 12 (consisting of FIG. 12A, FIG. 12B, and FIG. 12C) is a flowchart that shows an exemplary OGS process involved in creation of user-groups (pools), including a user joining one or more pre-created pools, for purposes of playing OGS games.

FIG. 13 is a flowchart that shows an exemplary front-end OGS process illustrating interactions triggered by the OGS as well as by system users, as part of an exemplary OGS game played between an embodiment of the OGS and system users.

FIG. 14 is a flowchart that shows an exemplary back-end OGS process involved in playing OGS games, including extraction of analytics from a live event data feed and historical event data, wherein such analytics are provided to system users and also utilized by an embodiment of the OGS.

DETAILED DESCRIPTION

For the purpose of promoting an understanding of the principles of the present disclosure, reference will now be made to the embodiments illustrated in the drawings and specific language will be used to describe the same. It will, nevertheless, be understood that no limitation of the scope of the disclosure is thereby intended; any alterations and further modifications of the described or illustrated embodiments, and any further applications of the principles of the disclosure as illustrated therein are contemplated as would normally occur to one skilled in the art to which the disclosure relates. All limitations of scope should be determined in accordance with and as expressed in the claims.

In the following text, references to items in the singular should be understood to include items in the plural, and vice versa, unless explicitly stated otherwise or clear from the text. Grammatical conjunctions are intended to express any and all disjunctive and conjunctive combinations of conjoined clauses, sentences, words, and the like, unless otherwise stated or clear from the context.

Overview

Aspects of the present disclosure generally relate to systems and methods for designing a social gaming platform, referred to in this disclosure as an Online Gaming System (OGS). According to one aspect, the OGS allows users to create online games in which participants compete to predicts the outcomes of specific conditions relating to activities at sporting events, TV award shows, or other types of contemporaneous events. For example, in one aspect and as will be understood from the discussions that follow, conditions can be in the form of multiple-choice questions, free-form questions that have answers comprising a few lines, tournament brackets, and the like. Therefore, in such examples, a game involves participants (OGS users) predicting the answers of questions. In an exemplary aspect, questions (or, more generally, conditions) comprise real-time in-event questions created by the OGS or by system users, or even pre-stored in the system

According to one aspect, in an online game (also referred to as an OGS game, or even simply, a game) players compete with other players in the same pool or different pools, via an online gaming platform administered by the OGS to predict outcomes of specific conditions relating to activities at various contemporaneous events.

According to another aspect, the OGS receives live digitized information feed from a contemporaneous event (while an event is currently in-progress) from third party sources. Additionally, the OGS also stores historical information relating to an event (e.g., sporting events, TV award shows, etc.), or generally, accesses historical information relating to an event from third party sources. It will be understood that such live-feed and historical information are presented to players (participants) as analytics for their guidance in predicting the outcomes of specific conditions relating to the activities at the event. Yet, in another aspect, the live-feed and historical information are also utilized by the OGS to extract analytics in predicting outcomes of specific conditions relating to activities at events. In one exemplary embodiment, pre-defined rules are used in conjunction with the analytics to formulate OGS-generated questions which are presented to players. A player who is able to predict answers with the greatest accuracy scores. Consequently, as the event progresses in real-time, more questions are presented to participants by the OGS, responses (answers) of the participants are received by the OGS, scored in near real-time based on analytics extracted from live digitized information feed from the event, and finally the players are ranked by the OGS.

Additionally, embodiments of the present system utilize geo-location information to enable creation of user-groups (pools) based on the physical location of system users and social network affiliation of users. As will be understood, in one embodiment an OGS game is played (via the OGS platform) in pools both before as well as during an event, e.g. football game, baseball game, etc. Nevertheless, it will be understood that a “game” as referred to herein may generally refer to an OGS-administered game, or a sporting event (such as a football game or a baseball game), and will be assumed that such a distinction will be implicit based on the associated context wherever applicable. Additionally, distinctions between the terms “user”, “member”, “player”, and “participant” as referred to herein will also be considered to be clear based on the associated context wherever applicable. Various specifics, details, and system embodiments will be better understood in the description provided in greater detail below.

Exemplary Embodiment

Referring now to the figures, FIG. 1 illustrates a conceptual overview one embodiment of the present Online Gaming System (OGS) in an exemplary environment, constructed and operated in accordance with various aspects of the present disclosure. Specifically and according to one embodiment, the OGS comprises a processor 1 that is connected to a web interface 4 for system users (not shown in FIG. 1) to access the OGS. In on embodiment, the OGS comprises a processor 1, an archive database 7, a content library 6, an analytics engine 5, a web interface 4, and a live database 3. Details of functions performed by the aforementioned components will be better understood with the help of the discussions provided in connection with FIG. 1, FIG. 1A, and FIG. 2.

As shown in FIG. 1, processor 1 communicates (typically through one or more communications networks, not shown) with an external data feed 2 that provides live digitized information feed at a periodic time interval (e.g., every thirty seconds) from an event, while an event is currently in-progress. Examples of sources that provides a live event data feed include STATS™ LLC, SPORTS™ DIRECT™ INC., among several others. Typically, in one embodiment, system users register with the OGS, and the user data is saved in an OGS database, exemplarily called the live database 3. Historical data relating to previous events (e.g., previous season's data) is usually stored in another OGS database, exemplarily called archive database 7. All generic contents (non-pool specific data), such as resources, “about us” information, event schedules, FAQs, etc. are stored in the content library 6 (also referred to in the accompanying drawings as content data table 6, or simply, content 6). Further, an analytics engine 5 is used to track user activity and collect user interaction data for OGS games. In one embodiment, the live database 3 and the archive database 7 are a conglomeration of several different databases and web servers (e.g., a database hierarchy), as will occur to one skilled in the art. As will be further understood and appreciated by one skilled in the art, a hierarchical database scheme enables greater flexibility when storing data and also provides for greater scalability.

FIG. 1A shows the various architectural components (and their associated interactions) included in one embodiment of the present system. In one OGS embodiment, the data feed 2 interacts only with the processor 1. Both the live database 3 and the archive database 7 interact with the processor 1. In one aspect, the processor 1 transfers data from the live database 3 to the archive database 7, in addition to processing various kinds of data.

Data from the live database 3 is stored and organized in several tables; including the content library 6 (also referred to in the accompanying drawings as content data table 6, or simply, content 6), a profile table 8, a score table 9 and a pool table 10. These tables are linked together by the live database 3 and provide the basis for all data in connection with an online OGS game. As will be understood, in one embodiment an OGS game is played both before as well as during an event. In another embodiment, game-related data is published to participants via a web interface 4 which can be accessed by participants 90 (not shown in FIG. 1A) who are typically connected via a computer 12, or a mobile device 11.

In yet another embodiment, the entire system is managed by a system administrator 13. The system administrator 13 has several duties and permissions that allow for smooth operation of the system as will occur to one skilled in the art. The system administrator 13 manages user accounts, core system questions and responds to feedback (from OGS users and non-users) and participant 90 questions. The system manager 13 is also responsible for general code updates and OGS platform maintenance. As will be understood and appreciated, according to various embodiments, many of the system administrator's functions and responsibilities are performed as human intervention-less automated processes. Details of exemplary OGS processes will be discussed later in connection with FIGS. 12, 13, and 14.

As will be understood by one skilled in the art, OGS communications proceed over networks (such as, but not limited to the Internet) and typically involve the usage of one or the other services, e.g., a Web-deployed service with client/service architecture, a corporate Local Area Network (LAN) or Wide Area Network (WAN), or through a cloud-based system. Moreover, as will be understood and appreciated, various networking components like routers, switches, hubs etc., are typically involved in the communications. Although not shown in FIG. 1 and FIG. 1A, it can also be further understood that such communications may include one or more secure networks, gateways/firewalls that provide information security from unwarranted intrusions and cyber attacks.

FIG. 2 further demonstrates an exemplary aspect of relationships between data and OGS components. The data feed 2 provides information to the processor 1. In one OGS embodiment, this data is then sent to a live database 3, organized (by the OGS) into various tables (e.g., profile data table 8, score data table 9 and pool data table 10) based on the type of the data, then processed for OGS games to extract analytics, and subsequently the analytics are published to the web interface 4. After the game or event has concluded, this data may be stored as historical data 110 in the archive database 7. This historical data 110 can be used by participants 90 in answering pool questions. In one exemplary embodiment, the system also generates occurrence probabilities 111 based on the past results of similar scenarios. Exemplary OGS processes that make use of data feed 2 and historical data 110 will be explained in connection with FIGS. 13 and 14.

FIG. 2A, FIG. 2B, FIG. 2C, FIG. 2D, and FIG. 2E display unique components contained in the data tables referenced by the live database 3. The profile table 8 shown in FIG. 2A contains the typical information utilized to create a profile 8. In one embodiment, the user ID 14 is included in each table and serves as the unique identifier used to relate the tables to each other and provide accurate data for the individual participant 90. The profile table 8 stores each member's 89 first name 15, last name 16, email address 17, password 18, zip code 19 and mobile phone number 20, and other information as will occur to one of ordinary skill in the art which are generally used to create a profile. The member 89 may also create a list of contacts 21 from other OGS members 89, which is stored in the profile table 8. Typically, in one aspect, the OGS allows OGS members to invite other OGS members or non-members to join one or more pools or user groups. (An exemplary pool creation process is described in connection with FIG. 12.) In another aspect persons listed under contacts 21 comprise such OGS members and non members. One embodiment of the present system records a member's 89 social media (e.g., FACEBOOK™, TWITTER™, LINKEDIN™, etc.) account information 112 in order to integrate with these social media networks and allow members 89 to add contacts 21 and automatically post updates to those social media networks. An exemplary OGS process to include a user's social media information is discussed in connection with FIG. 12.

The global rankings 22 are determined by comparing the individual participant's 90 total score (the aggregate total of the score fields 28 in a participant's score tables 9) to the scores of other participants 90. There are two global ranking 22 measurements. In one exemplary OGS game, a first ranking is the total ranking against every other participant 90 on OGS, while a second ranking compares players playing in the same pool or pool type 31.

FIG. 2B outlines the fields contained in one exemplary embodiment of the score table 9. The user ID 14 joins this table to the profile table, while pool ID 23 and participant 90 link this table to the pool table 10. In one OGS embodiment, an OGS game involves a participant 90 as well as the OGS asking questions to other game participants 90. When participants 90 submit responses to each question, each response will be recorded as the selection 25 corresponding to that question 27. After the game is complete, the correct answers 27 will be published to the web interface 4. The system will then compare each participant's 90 selections 25 with the actual answer 27 for each question 26 to create the participant's 90 score 28 and global ranking 22.

In regard to FIG. 2C, this diagram outlines the fields contained in one embodiment of the pool table 10. This table, like the score table 9, contains user ID 14, pool ID 23 and participant 90. Also contained in this table is participant type 24, which is either participant 90 or manager. The manager creates the pool, sets the pool type 31 and sends out invitations 30 for others to join the pool. An exemplary OGS process involved in a pool manager (pool creator) sending out invitations is described in connection with FIG. 12. As shown in FIG. 2C, standings 32 compare the scores of all participants 90 in the pool, while the pool listing 33 indicates whether the pool is public or private.

FIG. 2D shows the contents of one embodiment of the statistics data table group 116, which is used during game play to provide in-depth analysis of past and future results to questions. This table stores the question to be asked 26 and the teams 117 involved and queries the historical database 7 to find historical results. These results include, but are not limited to: head to head results 118, how the teams have fared against each other with respect to the specific question at issue; league results 119, how the league as a whole has succeeded with respect to the specific question at issue; team results 120, how the teams involved have historically succeeded with respect to the specific question at issue; player results 123, how individual players succeeded against player-based questions; and in-game results 121, what has occurred in the game thus far, relative to the question. The statistics table 116 also contains a predicted result 122, with the probability of each outcome based on the historical data contained in the table.

One embodiment of the content table 6, shown in FIG. 2E, contains information from the live database 3 that may not be necessary for the game-play functionality. For example, the data table 6 contains “about us” 34 information, “resources” 35, “search metadata” 36 and “demos” 40, “FAQs” 107 and “event schedules” 108. It also assists the system in communicating with members 89 through mobile alerts 37, notifications 38 and messages 39. As will be understood and appreciated by one of ordinary skill in the art, the specific servers, data tables, or any system components shown and described herein, as well as the exemplary data fields provided in each table, are shown for illustrative purposes only, and embodiments of the present systems and methods are not intended to be limited by those described herein. Various other types of data, tables, and system components are contemplated for inclusion in aspects of the present system as will occur to one of ordinary skill in the art.

FIG. 3 is a flowchart detailing the steps associated with registering and creating a user profile with the system according to one embodiment of the present system. A visitor to on online OGS platform typically (in one aspect) first either navigates to the OGS homepage 41 or clicks on an email invitation link 59. If the user enters through the homepage 41, and they have already registered 42, they can simply proceed to login 50 (the process of which is defined in FIG. 3A). If the user is not already registered, they can click the “Create a Profile” link 43 on a OGS user interface (web or mobile). After entering the required member 89 and account 45 information, the user may select favorite teams or leagues 46 (or other events or information). The member 89 information 44 and account information 45 generally includes user ID 14, first name 15 and last name 16, email address 17, password 18, zip code 19 and mobile phone number 20. Alternatively, a user clicking on an email link 59 is automatically sent to the pool page. At this point, the user submits answers to all the questions in a pool 76 and proceeds through the registration process as outlined above. According to a potential embodiment, the user may also register and log in to the OGS through a social media system, thereby linking a user's OGS and social media system accounts.

Upon clicking the “Register” button 47, at least two possible scenarios may occur 48. If there are errors in the required member 89 information 44 or account information 45, or if information is not complete, the system displays an error message and prompts the user to correct the errors and re-submit 51. Upon successful registration and profile creation, the member 89 is redirected to the “Join a Pool” section 49 and all member 89 data is stored in the profile table 8 (unless the member 89 entered through an email link 59 and is already entered into a pool).

FIG. 3A outlines one embodiment of the login process 50 for returning system members 89. The user typically either navigates to the homepage 41 login via a native mobile device application where userID 14 and password 18 are required, or enters via an email link 59 and login as outlined in FIG. 3. If the credentials are validated 53, the member 89 is directed to the “Pools” content area of the OGS interface. If responding to an invite, the member 89 is routed to the specific pool's detail page. If already a participant 90, member 89 is routed to the “My Pools” page. If not yet a participant 90, the member 89 is shown public pool and recommendation content. If the credentials are not validated, the user may re-enter credentials and attempt to log in again 54. Unsuccessful login attempts are generally governed by a security policy.

If the member 89 has forgotten login credentials, he/she can click the “Forgot Password” link 55. This link will open a modal via which the member 89 will enter his/her email address 56. This email address will be verified in the profile table 8, and upon verification, the system will send a message to that email address containing the corresponding user ID and password 58. At this stage, the user will retrieve his/her credentials and login 50.

FIG. 4 is a flow chart that outlines one embodiment of the process for creating a new pool. Pools can be created by any member, and the system (in one embodiment) automatically generates public pools for all sports, leagues, teams and games. Assuming that a member 89 has registered and logged in (as outlined in FIG. 3 and FIG. 3A), the member 89 may create a pool (exemplarily shown in FIG. 12) by navigating to the “Create a Pool” section 66 and thus assumes the role of pool manager 91. To create a pool, there are several steps required. The pool manager 91 must name the pool 67 (stored in the pool table 10 as pool ID 23) and set the pool as either public or private. If the pool manager 91 makes the pool private, a password will be required to join and the pool will not be searchable. If the pool is public, it will be searchable by all web visitors to the OGS portal and also any member 89 will be able to join. The system then guides the pool manager 91 to select a pool type31 through a multi-step process. The pool manager 91 selects the pool's sport 68 (college football, NFL, etc.), game-play style 69 and conference or team 70.

According to various embodiments, there are a variety of game-play types supported by this system. For example, one game-play type is a classic “pick ‘em” format. In this type of game-play, the pool manager 91 selects a division or conference in his/her chosen sport and pool members 89 simply pick the winners of all games in that division or conference, respectively. The scores will be compiled throughout the season, with the winner being the participant 90 who has picked the most games correctly at the end of the season.

Another example of a type of play is a single game pool. In this type of pool, the pool manager 91 selects one game and participants 90 are required to answer a series of questions regarding outcomes and events of that game. This game play type is modeled after proposition bets offered by sports books and proposition pools that are popular during the NFL Super Bowl. Participants 90 answer a pre-defined list of questions about game events such as “Which team will gain the most rushing yards?” or “Will there be a fumble in the first half?” The participant 90 who accumulates the most points wins the pool. Points are generally awarded at the rate of one point per question answered correctly, but this may vary based on time remaining, question difficulty, or other factors.

In another example, the game-play type comprises a team and/or conference pool. In this pool, the pool manager 91 picks either a single team and/or a conference. Similar to the single game pool, participants 90 are required to answer questions about the game(s) which that team or conference is playing. The main differentiator between a team pool and a game pool is that the team pool follows a team for an entire season, while the game pool is only active for a single game. Participants will be ranked over the entire season on both total points and percentage of questions answered correctly, allowing those who join after the season has started to play without being at a significant disadvantage.

A specific variation of the team/conference pool is the tournament pool, which can be used for tournaments such as the NCAA Men's Basketball Tournament. In this pool format, the tournament is treated as a ‘team’, each round represents a ‘game’ and the ‘season’ is the duration of the tournament. In order to make each round worth the same number of points as the number of games per round decreases, additional questions may be added for each game and/or the point values for each question may increase. Using the NCAA basketball tournament as an example, the first round (with 32 games) would require participants 90 to predict the winners of each game for one point each. The final round (only one game) would ask 8 questions about the game, worth 4 points each. Each question will include statistics showing how teams have fared in each question topic throughout the tournament. Participants 90 will then be ranked on total points and percentage of correct answers. This is unique compared to most other tournament pools in that the participant 90 makes new selections each round, rather than making all picks before the tournament starts, thus increasing engagement throughout the tournament. Another aspect of the present system is the ability to combine multiple pool types to create a custom pool. In this case, a pool manager 91 who wants to create a pool that closely follows an NFL team while also tracking scores from a football conference can do so by creating a pool to include both an NFL team pool and a college conference pick ‘em pool. If at some point during the season the pool manager 91 may introduce additional games to the pool, he/she can create a game pool and add the scores from that game pool into the overall pool scores and standings.

As will be understood and appreciated, there is a virtually unlimited number of game-play types that may be incorporated by aspects of the present system, and each of these types is contemplated by various system embodiments, as will occur to those of ordinary skill in the art.

Still referring to FIG. 4, once the pool manager 91 has determined the pool type, he/she is allowed to review pool info 71 before proceeding to any other steps. The next step in the process is to invite participants 90 to join the pool. Participants 90 may be invited 72 either by email, through the pool manager's 91 contacts 21 already signed up for the system, or via social network (social media system) invitations. After inviting participants 90, the pool manager 91 has the option to either create custom questions 73 or confirm and submit pool info 74. The pool manager 91 may return and invite more participants 90 at any time.

The pool manager 91 may add custom questions 73 upon creation of the pool and prior to each game. He/she may choose from a variety of different statistics and time periods that may not be set as the system-generated questions. The pool manager may also create non-statistical questions, for which the answer will be provided by the pool manager rather than the system. These questions may be non-statistical in nature and could include questions such as “How many players will lose a helmet during the game?” or “Who will win the coin toss?”

According to one embodiment, potential participants may join pools by navigating to a OGS web interface (on the WWW) or clicking on an email link. FIG. 5 refers to one embodiment of the process of joining a pool by navigating an OGS platform. Generally, a visitor to the platform enters through general navigation 41. If the visitor is not a registered user 42 and entered via the homepage 41, he/she must first register using the process demonstrated in FIG. 3, or enter his/her credentials and login 50. Once the member 89 has logged in, the system will display the “My Pools” page 57 (as with any member login). This page will display if the member 89 has any open pool invitations. If the user has been invited to a private pool 60, they will click on the email link 59 and proceed to answer pool questions 76. If the member 89 does not have any open invitations, he/she may search available pools 62 and view pool listings 63. Only public pools will be visible and available to join. After viewing the pool details page 64, the member 89 can click to join the pool 65 and change roles to become a participant 90.

FIG. 5A outlines one embodiment of the process of joining a pool from an email link. After the pool manager has sent an invitation to the potential participant's email address 72, that person clicks the invitation link in the email. The participant then is redirected to the pool screen to answer the current week's questions. After the answers have been submitted 76, the participant is asked to login 50. The user is then redirected back to the pool details 64 page and the score table 9 and pool table 10 are updated with the participant's answer data.

FIG. 6 outlines one embodiment of the basic pool play workflow. Prior to the game (e.g., an underlying event, sports game, etc.), the system will send notification of new questions to all participants 90. The participant 90 then navigates to the OGS homepage 41, logs in 52 and submits answers 76, or may click on the link in the notification email 59, submit answers 76 and then login 52. The pool manager 91 or system can also generate custom questions 73 which would trigger additional notifications 75 to be sent. While answering questions, the user will have the opportunity to view historical data and see predicted outcomes 115 via the statistics table 116. This data will be displayed in a user friendly view to assist the user in answering the questions. In one embodiment, this predictive data and suggestions are generated by the system based on predefined system parameters and identification of historical trends in similar types of data. The historical information may be obtained directly from the data feed or may be calculated from the raw data this feed provides.

In one embodiment, the participant 90 may return to the OGS platform after having submitting answers so as to edit the previously submitted answers until the game starts. During game-play, participants 90 can review in-play progress, post and view user-generated content 77, etc. Generally, participants 90 receive in-game updates 99 while games are in progress and the participants' 90 scores and rankings will be tallied upon conclusion of the game 100.

One aspect of embodiments of the present system is the interface and game-play during live games, as demonstrated in FIG. 6A. At the start of the game 101, the participant's 90 answers to the original questions lock and the participant 90 is no longer allowed to edit those responses. At this point, the participant 90 will be able to view real-time updates of events occurring in the game, as well as the effect those events are having on standings in the pool. Whenever an event occurs in the game 102 that is related to one of the questions, the system updates the participant's 90 score and victory odds 103. It also shows what events must occur in the game from that point on for the participant 90 to earn the highest possible ranking available. According to one potential embodiment, the system will also include a predictive engine, which will show the odds that a participant's answer will be correct, based on an algorithm derived from historical data, previous in-game events, and game pacing. This predictive engine may also show how the participant's odds changed during the course of the game.

Another aspect of embodiments of the present system is an in-game or in-event functionality that enables a pool manager 91 or the system itself (running on predetermined algorithms) to create questions as the game (or an event) progresses 105. These questions are then sent to the participants 90, who should respond 106 before the question outcome is resolved. For example, the manager could create a question about whether or not a team will make a field goal as the game goes into a commercial break and the participants 90 will have until the break ends and the kick is attempted to respond with their answer to earn points. This functionality is particularly desirable in locations where sports fans gather to watch games (e.g., at a sports venue, at a pool manager's home, etc.). Details of OGS processes involved in OGS games are explained with flowchart steps in FIG. 13 and FIG. 14.

FIG. 7 is an outline of one embodiment of the overall system data flow. As shown, the system communicates with a third-party application to retrieve data feed for game updates 78. As will be understood and appreciated, data and information relating to events need not be collected from a third-party application, but may be obtained from other sources. If an update is available 79, the system retrieves the data 80, but if not, the system will alert the administrator 87 and continue to display the most recent information available 88. After the data is received 80, it is downloaded and stored locally 81 then parsed 82. The data is processed 83 and related score 84 and pool 85 data tables are updated. Updates are continuously published to the interface 86.

FIG. 8 shows one illustrative embodiment of user characteristics from a system-perspective. There are generally at least four user roles: member 89, participant 90, pool manager 91 and system administrator 92. Members 89 are not involved in any game-play on the OGS platform but have created a profile and have full access to search, join or create pools. Participants 90 have joined one or more pools and may view the pools they have entered and respond to questions. They may also search additional pools and create pools, but are not allowed to create questions or perform other management tasks for pools. Pool managers 91 may perform all activities a participant 90 or member 89 can, but may also create custom questions and perform management tasks. The system administrator 92 has access to all areas of the OGS gaming platform and may perform other tasks such as edit pools or remove members 89 from the OGS gaming platform. The administrator also has the ability to create in-game questions for a large group of participants 90 as was mentioned when discussing FIG. 6A. As will be understood, various system users may comprise one or all of the roles defined in FIG. 8.

FIG. 8A represents some of the personas that may engage with the present system, at least according to a sports-related embodiment. There is a very broad group of sports fans 94 of varying levels of interest and engagement who may visit this OGS platform 95. Participants 90 may be divided up into three main personas: the fantasy freaks 97 participate in fantasy leagues, tracking the statistics of players across different teams in order to create the best “fantasy team;” the diehard fanatics 96 have a specific team or teams that they follow intently and they live and die with the success of that team; the office casuals join the pool because their friends or co-workers are playing, and they may only have a minor interest in sports. Most participants 90 will be a combination of these three personas and the pool play featured in this system is designed to enable all personas to have an enjoyable gaming experience.

FIG. 9 is a flow chart outlining one embodiment of the process for creating and participating in a location-based venue pool. These venue pools can be generated by system users (members) acting as the pool manager 91, by the venue 107 itself or be automatically generated by the system processor 1 (especially at large venues such as stadiums). People congregating at a specific venue (e.g. bars, stadiums, etc.) 107 or viewing the same event from a variety of locations can access the OGS gaming platform through either a computer 12 or mobile device 11. In the embodiment shown, the member 89 logs into the OGS gaming platform and “checks in” to the venue using a location-aware check-in application 108. This application identifies the location the member 89 is checking in from and identifies other members 89 who have logged in to the same location. After logging in 108, a member may create a venue pool 109 for the location. In one embodiment, this type of pool will automatically invite any other members who check in to that location to join. Once the venue pool has been created 109, the pool manager 91 may create custom questions 73 both before and during the game. Participants 90 who have checked into the location 108 then answer these questions 105 and victory odds are updated 103 at the conclusion of each in-game event 102. At the end of the game 106, each participant's final scores are added to the rankings 100.

FIG. 10A illustrates one embodiment of a user interface for accessing embodiments of the present system. Upon logging into the system, the system displays this interface, which is customized for the individual participant. As shown, the user interface exhibits various data display fields and entry fields, such as a player rankings field, pool status fields, messages field, and various other fields as will occur to one of ordinary skill in the art. The header bar 1110 will be displayed on all pages within the logged in area of the OGS platform, and will allow the user to navigate between the various sections of the OGS platform, e.g., Pools, Create a Pool, Rankings, Resources, and others. As shown in FIG. 10A, the screenshot displays the user's global ranking in region 1120, pool ranking and status in region 1130, and messages in region 1140. The user is also able to view details about the status of any upcoming sporting events in region 1150 and view/edit answers for these sporting events in region 1160 of FIG. 10A.

FIG. 10B illustrates an exemplary screenshot of a user interface for pool participation within the present system. Within this interface, the system will display the user's ranking and status within the pool as outlined in region 1200. Additionally, the system, in one embodiment also displays various actions taken by the user, with respect to the displayed pool. Examples of such actions include, but are not limited to, viewing pool rankings and messaging the pool manager. For each specific game that is a part of the pool, the user will be able to complete certain actions depending on a current status of the game. For example, prior to the start of a game, the user may view and edit picks and answers, (e.g., in region 1170). During the sporting event, the user may participate while a sporting event is in process (as shown in region 1180), or after the sporting event is over, the user may view the results of a game (e.g. in region 1190). At all times, the user's game rank and possible points will be displayed for each game shown.

FIG. 10C illustrates an exemplary screenshot of the web interface for answering or editing sports events-related questions prior to the start of the event. This screen displays the user's pool status in region 1200 as well as the status of the individual game in region 1210. For each question related to the game, the user may select an answer (e.g., as shown in region 1240) and save selections by clicking on button 1220. A collapsible interface showing statistics 1250 relevant to each question may also be displayed.

FIG. 10D illustrates an exemplary screenshot of the web interface for the Live Play functionality. This view will display the status of questions answered prior to the game 1270, as well as any questions that may be available to answer during the game. As questions are resolved during the game, the system will award and display points to participants who were correct 1280. The system will display the results of rival pool members and live standings within the game status header 1260. A live game feed 1300 will be provided to inform players about events occurring within the game.

FIGS. 11A-11D illustrate exemplary screenshots of the mobile interface corresponding to the web interface described above. The mobile interface will maintain the functionality available in the web interface, but the display will be optimized for mobile devices. In some cases, such as when answering game questions as displayed in region 1290, this may require the user to make an extra click to display more information. As will be understood and appreciated, the exemplary user interface embodiment shown in FIGS. 10A-10D and FIGS. 11A-11D are presented for illustrative purposes only, and is not intended to limit the scope of the present disclosure in any way. In alternate system embodiments, aspects of the OGS can be integrated as an application program (e.g., as a part of a social media system, or as a stand-alone mobile device application program). Details of such embodiments follow next herein.

From the above discussions, it will be apparent embodiments of the disclosed system (referred to herein as the OGS) are involved in the design of a mobile and web-based social gaming platform in which a game (also referred to as an OGS game, or an online game, or an online social game) involves players compete with each other (or with the OGS) to predict outcomes of specific conditions relating to activities at various events (e.g., sporting events such as basketball games, football games, TV shows, entertainment events, etc.). In one aspect, and as will be understood from the discussions that follow, conditions can be in the form of multiple-choice questions, free-form questions that have answers comprising a few lines, tournament brackets, and the like. Exemplarily, this could mean users (players) providing answers (i.e. predicting outcomes) to questions (e.g., in a football game, “will Team X score a touchdown in the first half?”) as a part of an online social game, wherein questions depend on one or more activities (e.g., touchdown) at the event (football game). In one embodiment, questions presented in an online game can be pre-event and stored in the OGS, and in another embodiment, such questions can be in-event questions, i.e., formulated by the OGS and users while an event is unfolding in real-time.

Typically, in one embodiment, participants receive the questions via email, mobile push notifications, mobile text alerts, MMS, computer interfaces, from the OGS as pre-event questions (i.e. prior to an event), or even, in-event (i.e. while an event is in-process). Participants of pools can then respond via mobile or web back to the OGS that then scores these questions, adjusts pool scoring, and displays rankings of users in near-real time. In one aspect, users are arranged in pools (groups) and wherein users compete with other users within the same, or sometimes, different pools, via an online gaming platform administered by the OGS. In what follows next, an exemplary OGS process involved in pool creation, including a user joining one or more pre-created pools will be described.

Referring to FIG. 12 (consisting of FIG. 12A, FIG. 12B, and FIG. 12C), an exemplary OGS process 2000 is shown, including steps involved in creation of user-groups (pools) for purposes of playing OGS games. Starting at step 2002 (in FIG. 12A), the OGS receives user credentials by a web or a mobile interface. Examples of user credentials include username, password, user's memberships with various social media systems (e.g., FACEBOOK™, TWITTER™, LINKEDIN™ etc.) and various location based social networks (LBSNs), such as LOOPT™, FOURSQUARE™, BRIGHKITE™, FACEBOOK™ PLACES™, GOOGLE™ LATITUDE™, GOWALLA™ to name a few. As will be understood by one of ordinary skill, a social media system provides information relating to social affiliations (high school, college, work, memberships with various social, political, non-profit organizations, etc.).

A LBSN, on the other hand, provides information relating to a user's location. For example, when a LBSN user is at a venue such as a restaurant, a bar, or a football game, then the user “checks in” with one or more respective LBSNs. The respective LBSNs then broadcast the LBSN-user's current venue (or related information) to various location-responsive system (e.g., the present OGS) and social media systems, thereby allowing friends and connections of the user to be aware of the user's social activity in connection with a venue.

Thereafter, at step 2004, the OGS communicates with the user-specified social media systems and LBSNs to extract information relating to a user's social affiliations (friends, family, work connections, contacts, current location, etc.) and/or current location. As will be understood and appreciated, this allows users having similar background, affiliations or interests to be a part of the same pool. At step 2006, the respective social media systems and LBSNs respond with information relating to a user's social affiliations and/or current location. Information received from various disparate (heterogeneous) social media systems and LBSNs is typically in different data fields/header, different file formats, etc. Thus, at step 2008, the OGS normalizes such disparate information into a common format that would allow in storage, accumulation, and utilization.

According to one aspect, the system can also create user groups (pools) based on pool-related information (e.g., NFL games, NCAA games, entire season games for a team, weekend-specific games, etc.). It will be understood that creating a pool involves creating an entry in a database with various pool-related information and fields, e.g., as shown in FIG. 2B, 2D and other drawings.

Next, at step 2010, the OGS applies normalized information (corresponding to a user's social affiliations and/or location) against information pertaining to pre-created pools, wherein the pools can be either pre-created by system users, and/or the OGS. It will be understood that step 2010 is performed in order to establish a match between a user and one or more pre-created pools. Further, it will be understood that step 2010 involves computer-implemented aspects of data mining, data comparison, and several other computer methodologies as will occur to one skilled in the art. Eventually, at step 2012, the OGS displays one or more pre-created pools to the user based on the match established in step 2010. Although not shown in FIG. 12A, it will be understood that if a match is established and the user selects to join one or more displayed pre-created pools, then in one embodiment, the OGS creates a database association between the user and the one or more displayed pre-created pools that the user selects to join. Subsequently, and also in the event that no match is established at step 2010, the process moves to a next step 2014.

At step 2014, the OGS determines whether or not the user wishes to create a new pool. If the OGS determines that the user does not wish to create a new pool, then the OGS process provides (at step 2016 as shown in FIG. 12B) a search option to the user so that he or she can search for available pools in the database. In turn, the user searches for available (pre-created) pools in the OGS database. If, at next step 2018, the OGS determines that the user's search resulted in the user selecting one or more pre-created pools, then at step 2020, the OGS creates a database association between the user and the one or more displayed pre-created pools that the user selects to join. Consequently, the OGS process ends thereafter. Although not shown in FIG. 12B, in one embodiment, prior to creating the database association, the OGS also displays to the user additional information (e.g., name of the pool, participants in the pool, and various other details) relating to the one or more pre-created pools that the user has selected to join.

Referring back to FIG. 12A, if at step 2014, the OGS determines that the user indeed wishes to create a new pool, then the process moves to step 2022 as shown in FIG. 12C. At step 2022, the OGS receives pool-related information from the user. Examples of pool-related information include name of a pool, a type of a pool (public/private), one or more events corresponding to the pool and accompanying details (NCAA tournament, NFL game, NBA postseason game, reality TV episode/season, etc.) of the event, names/emails of persons (users as well as non-users of OGS) whom the user intends to invite in the pool, time duration for which the pool will be active, location-specific details such as whether the pool is in a certain geographical area, and various other pool-related information.

Then, at step 2024, the OGS creates a database entry corresponding to the user's newly created pool. Next, the OGS retrieves information relevant to the newly created pool from the database, such information comprising historical information, system-created and user-created questions pre-stored in the database, and other attributes. As will be understood from the previous discussions, in one aspect, the OGS collects historical information (e.g., previous statistics and performance of teams, players, awards, winners, MVPs, etc.) about events. For example, such information is stored in an archive database, as shown in FIG. 1, FIG. 1A, FIG. 2, and FIG. 2D. Thus, such historical information is retrieved at step 2026. Additionally, in another aspect, the OGS also retrieves at step 2026 system-created and user-created questions pre-stored in the database, as part of information relevant to the newly created pool.

Subsequently, at step 2028, the system creates a database association between the entry (created at step 2024) and information relevant to the newly created pool (retrieved at step 2026). In one alternate embodiment, the OGS also allows users to invite other OGS users and non-users to join a user's pool. In such a scenario, at step 2030, the OGS transmits invitations to the invitees based on the pool-related information provided by the user at earlier step 2022. Finally, the OGS process exits thereafter. It will be understood that the steps discussed in connection with the above flowchart are for illustrative purposes only, and not intended to limit the scope of the present disclosure. Alternate embodiments of the CMS can involve variations of the steps discussed herein. In one OGS embodiment, users typically play OGS games interactively with other users in the same pool or with users in different pools via the OGS platform. Such an embodiment will be explained in greater detail in what follows next.

Now referring to FIG. 13, an exemplary OGS process 3000 is shown that illustrates aspects of the OGS steps performed as part of an OGS game involving users and the OGS. From our previous discussions, it will be generally understood that in one aspect, the OGS games involve players predicting outcomes of specific conditions relating to activities at various contemporaneous events (e.g., sporting events such as basketball games, football games, TV shows, entertainment events, etc.). In one aspect, and as will be understood from the discussions that follow, conditions can be in the form of multiple-choice questions, free-form questions that have answers comprising a few lines, tournament brackets, and the like. Exemplarily, this could mean users (players) providing answers (i.e. predicting outcomes) to questions (e.g., in a football game, “will Team X score a touchdown in the first half?”) as a part of an online social game, wherein questions depend on one or more activities (e.g., touchdown) at the event (football game). In one embodiment, questions presented in an online game can be pre-event and stored in the OGS, and in another embodiment, such questions can be in-event questions, i.e., formulated by the OGS and/or users while an event is unfolding in real-time. For the purposes of example and explanation, in the discussions (and accompanying flowchart) that follow, predicting outcomes of activities at events is considered to be conceptually synonymous with providing answers to questions. However, such a consideration will be considered to be non-limiting and non-exhaustive, without limiting the scope of the disclosure.

Starting at step 3002, in one OGS embodiment, one or more pre-event questions stored in the OGS database are displayed to users. As will be understood, such questions can be user-created or OGS-created beforehand in time. In one aspect, answers to the pre-event questions depend on an event that has not yet started, and the OGS starts the game by allowing users to guess most likely answers to the questions. In another aspect, the pre-event questions are based on trivia (past statistics and team performance etc.) of the event.

Next, the OGS receives (at step 3004) answers for the questions from users as entered by users via their electronic device, and stores them in an exemplary OGS database. Typically, as will be understood, the event corresponding to the game has not yet started, and hence steps 3002, 3004, and 3006 are pre-event steps. It will be understood that in alternate embodiments, pre-event questions are neither created by the OGS, nor by OGS users. Further, as recited previously, in one exemplary aspect, players join pools in order to play OGS games. In such scenarios, OGS games can be played by inter-pool or intra-pool players. Steps involved in a pool creation and/or users joining pre-created pools were described earlier in connection with FIG. 12 (consisting of FIGS. 12A, 12B, and 12C).

As shown in FIG. 13, at step 3008, the OGS receives an indication corresponding to start of an event. Consequently, the OGS process jumps into an in-event mode with an exemplarily backend OGS process 4000 (workings of which are described in FIG. 14) being engaged in computing answers to pre-event questions and in-event questions. In one aspect, in-event questions are formulated by the OGS as well as the players (system users). In another aspect, the backend OGS process 4000 computationally generates a closest proximate answer to the questions based on analyzing live event data and past historical data relating to the event, and further stores the closest proximate answer in a database. Such an answer is retrieved (at step 3010) by the OGS and used to rank (at step 3012) participants (players) who have been involved in answering the question whose answer is retrieved at step 3010. It will be further understood that typically the ranking is performed based on a degree of closeness between the participant-provided answer and the closest proximate answer retrieved at step 3012. As will occur to those skilled in the art, in many scenarios, for providing answers to certain pre-event questions, the OGS may be required to wait for a time duration that could be known or even, sometimes unknown for an activity (e.g., a touchdown, a field goal, and various others) to occur at an event. Further examples of activity include a number of rushing yards, a number of catches, a number of quarterback sacks, a number of wickets, a number of home runs, etc. In some scenarios, activities can involve persons involved in an event (a name of a person who has possession of the football, a name of a person who wins an award etc.).

Rankings (as determined from step 3012) of the players playing the OGS game are displayed (at step 3014) to the players. In alternative aspects, the OGS uses the rankings to tabulate players' scores (based on a pre-determined point system). Then, as shown at step 3016 in FIG. 13, the OGS determines whether or not the event (that was indicated as having started at step 3008) has ended. If the event has ended, the OGS determines and displays the final rankings of the players, and thereafter the OGS process exits.

If, on the other hand, the OGS determines that the event has not yet ended, then the OGS waits for a trigger for an in-event question. If no such trigger is received, and the event has not yet ended, the OGS reverts back to process 4000 and returns from therein at step 3010 as discussed earlier.

Next, in the event of a trigger, the OGS determines (at step 3020) whether or not, the trigger was created by a user or the OGS itself. If the trigger determines that the trigger was user-created, then at next step 3024, the OGS receives an in-event question from the user who created the trigger. Alternately, if the trigger was system-created, then the OGS retrieves (at step 3022) an in-event question from the database. In one exemplary embodiment, an OGS process formulates in-event questions with or without the help of a digitized live event feed (e.g., as shown in FIG. 1, FIG. 1A, and FIG. 2).

Regardless of whether the trigger was user-created or system-created, the OGS displays (at step 3026) to players of the OGS game the in-event question relating to this trigger. Subsequently, the answers from the players are received (at step 3028) by the OGS and stored (at step 3030) in a database. Subsequently, the OGS reverts back to the backend process 4000 for computing a closest proximate answer, the OGS operation performing in a loop from step 3010 onwards, as discussed earlier, until the event has ended.

As will be understood, the steps of the process 3000 shown in FIG. 13 are not necessarily completed in the order shown, and various steps of the OGS may operate concurrently and continuously. Accordingly, the steps shown in FIG. 13 are generally asynchronous and independent, computer-implemented, tied to particular machines (including various modules/engines of the OGS, coupled to databases), and not necessarily performed in the order shown. Details of a OGS backend process will now be provided below.

Referring to FIG. 14, an exemplary backend OGS process 4000 involved in computation of answers to pre-event and in-event questions as a part of a OGS game, will now be described. Starting at step 4002, the OGS receives digitized live event feed (e.g., as shown in FIG. 1, FIG. 1A and FIG. 2) from multiple third party sources. Examples of such sources include STATS™ LLC, SPORTS™ DIRECT™ INC., among several others. Communication between the OGS and third party sources proceed typically via Application Programming Interfaces (APIs). Digitized live event feed received from third party sources are exemplarily in the form of formatted XML files, although other file formats can be possible in alternate embodiments. Next, at step 4004, the OGS parses the received feed according to keywords corresponding to activities at the events. For example, keywords in a sports event can include (but are not limited to) running yards, rushing yards, throws, passes, wickets, downs, etc. Then, at step 4006, the OGS applies pre-defined rules on parsed live data feed to extract analytics that will be used in a subsequent step (e.g., step 4012) to compute a closest proximate answer. Thus, the OGS saves the extracted analytics at step 4008 in an exemplary OGS database.

At step 4010, the OGS retrieves a question (in-event and pre-event) from the database, and then identifies (at step 4012) a closest proximate answer to the question based on the extracted analytics. In an exemplary OGS embodiment, in-event and pre-event questions are received and processed as described earlier in connection with FIG. 13. Further, it will be understood that step 4012 involves computer-implemented aspects of data mining, data comparison, and several other computer methodologies as will occur to one skilled in the art. Finally, at step 4014, the OGS stores a closest proximate answer (to the question retrieved at earlier step 4010) in an OGS database, and then loops back to step 4002 in order to receive the digitized live event data feed.

Although not shown herein, it will be understood that in alternate embodiments, steps involved in a backend OGS process (e.g., as shown in FIG. 14) can be integrated with other OGS processes, as will occur to those skilled in the art. Even further, various other information can be stored in the OGS database(s), and are not limited to the ones described herein. Also, functionalities of various modules/software components and hardware components can be combined into a single or even multiple module(s), possibly with other functionalities as will occur to one of ordinary skill in the art.

As described in detail above, aspects of the present disclosure generally relate to systems and methods involved in the design of a online gaming platform in which participants compete to determine who best predicts the outcomes of conditions relating to activities at sporting events, TV shows, or other types of contemporaneous events. As described herein, such a system has been referred to as an Online Gaming System (OGS). System users (OGS users, or simply users) can access an OGS user interface (UI) over a computer network, such as the World Wide Web (WWW), using varying types of electronic devices such as mobile devices and computers. Accordingly, it will be understood from the foregoing description that various embodiments of the present system described herein are generally implemented as a special purpose or general-purpose computer including various computer hardware as discussed in greater detail below. Embodiments within the scope of the present disclosure also include computer-readable media for carrying or having computer-executable instructions or data structures stored thereon. Such computer-readable media can be any available media which can be accessed by a general purpose or special purpose computer, or downloadable through communication networks. By way of example, and not limitation, such computer-readable media can comprise physical storage media such as RAM, ROM, flash memory, EEPROM, CD-ROM, DVD, or other optical disk storage, magnetic disk storage or other magnetic storage devices, any type of removable non-volatile memories such as secure digital (SD), flash memory, memory stick etc., or any other medium which can be used to carry or store computer program code in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer, or a mobile device.

When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or a combination of hardwired or wireless) to a computer, the computer properly views the connection as a computer-readable medium. Thus, any such a connection is properly termed and considered a computer-readable medium. Combinations of the above should also be included within the scope of computer-readable media. Computer-executable instructions comprise, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing device such as a mobile device processor to perform one specific function or a group of functions.

Those skilled in the art will understand the features and aspects of a suitable computing environment in which aspects of the disclosure may be implemented. Although not required, the present disclosure is described in the general context of computer-executable instructions, such as program modules or engines, as described earlier, being executed by computers in networked environments. Such program modules are often reflected and illustrated by flow charts, sequence diagrams, exemplary screen displays, and other techniques used by those skilled in the art to communicate how to make and use such computer program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types, within the computer. Computer-executable instructions, associated data structures, and program modules represent examples of the program code for executing steps of the methods disclosed herein. The particular sequence of such executable instructions or associated data structures represent examples of corresponding acts for implementing the functions described in such steps.

Those skilled in the art will also appreciate that the present disclosure may be practiced in network computing environments with many types of computer system configurations, including personal computers, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, networked PCs, minicomputers, mainframe computers, and the like. The present disclosure is practiced in distributed computing environments where tasks are performed by local and remote processing devices that are linked (either by hardwired links, wireless links, or by a combination of hardwired or wireless links) through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

An exemplary system for implementing the present disclosure, which is not illustrated, includes a general purpose computing device in the form of a conventional computer, including a processing unit, a system memory, and a system bus that couples various system components including the system memory to the processing unit. The computer will typically include one or more magnetic hard disk drives (also called “data stores” or “data storage” or other names) for reading from and writing to. The drives and their associated computer-readable media provide nonvolatile storage of computer-executable instructions, data structures, program modules, and other data for the computer. Although the exemplary environment described herein employs a magnetic hard disk, a removable magnetic disk, removable optical disks, other types of computer readable media for storing data can be used, including magnetic cassettes, flash memory cards, digital video disks (DVDs), Bernoulli cartridges, RAMs, ROMs, and the like.

Computer program code that implements most of the functionality described herein typically comprises one or more program modules may be stored on the hard disk or other storage medium. This program code, as is known to those skilled in the art, usually includes an operating system, one or more application programs, other program modules, and program data. A user may enter commands and information into the computer through keyboard, pointing device, a script containing computer program code written in a scripting language or other input devices (not shown), such as a microphone, etc. These and other input devices are often connected to the processing unit through known electrical, optical, or wireless connections.

The main computer that effects many aspects of the present disclosure will typically operate in a networked environment using logical connections to one or more remote computers or data sources, which are described further below. Remote computers may be another personal computer, a server, a router, a network PC, a peer device or other common network node, and typically include many or all of the elements described above relative to the main computer system in which aspects of the present disclosure are embodied. The logical connections between computers include a local area network (LAN), a wide area network (WAN), and wireless LANs (WLAN) that are presented here by way of example and not limitation. Such networking environments are commonplace in office-wide or enterprise-wide computer networks, intranets and the Internet.

When used in a LAN or WLAN networking environment, the main computer system implementing aspects of the present disclosure is connected to the local network through a network interface or adapter. When used in a WAN or WLAN networking environment, the computer may include a modem, a wireless link, or other means for establishing communications over the wide area network, such as the Internet. In a networked environment, program modules depicted relative to the computer, or portions thereof, may be stored in a remote memory storage device. It will be appreciated that the network connections described or shown are exemplary and other means of establishing communications over wide area networks or the Internet may be used.

In view of the foregoing detailed description of preferred embodiments of the present disclosure, it readily will be understood by those persons skilled in the art that the present disclosure is susceptible to broad utility and application. While various aspects have been described in the context of a preferred embodiment, additional aspects, features, and methodologies of the present disclosure will be readily discernable from the description herein, by those of ordinary skill in the art. Many embodiments and adaptations of the present disclosure other than those herein described, as well as many variations, modifications, and equivalent arrangements and methodologies, will be apparent from or reasonably suggested by the present disclosure and the foregoing description thereof, without departing from the substance or scope of the present disclosure. Furthermore, any sequence(s) and/or temporal order of steps of various processes described and claimed herein are those considered to be the best mode contemplated for carrying out the present disclosure. It should also be understood that, although steps of various processes may be shown and described as being in a preferred sequence or temporal order, the steps of any such processes are not limited to being carried out in any particular sequence or order, absent a specific indication of such to achieve a particular intended result. In most cases, the steps of such processes may be carried out in a variety of different sequences and orders, while still falling within the scope of the present disclosure. In addition, some steps may be carried out simultaneously.

Accordingly, while the present disclosure has been described herein in detail in relation to preferred embodiments, it is to be understood that this disclosure is only illustrative and exemplary of the present disclosure and is made merely for purposes of providing a full and enabling disclosure. The foregoing disclosure is not intended nor is to be construed to limit the present disclosure or otherwise to exclude any such other embodiments, adaptations, variations, modifications and equivalent arrangements, the present disclosure being limited only by the claims appended hereto and the equivalents thereof. 

1. A method for conducting an online game via an Online Gaming System (OGS) involving a plurality of participants that participate in the online game via software operating on respective electronic devices of the plurality of participants, wherein the online game corresponds to a physical event happening in real-time, and wherein participants of the online game are associated with a specific geographic location, comprising the steps of: receiving game-related information at the OGS corresponding to one or more characteristics that define a particular online game, wherein the game-related information includes location information defining a particular geographic location associated with the particular online game; generating an entry in an OGS database for the particular online game based on the received game-related information, and storing the received game-related information in the OGS database in association with the entry for the particular online game; receiving participant information at the OGS from one or more participants indicating an interest by the one or more participants in participating in the particular online game, wherein the participant information includes participant location information corresponding to a specific geographic location of an electronic device associated with each respective participant; determining if the participant location information for each respective participant satisfies the location information defining the particular geographic location associated with the particular online game; for each participant whose participant location information satisfies the location information defining the particular geographic location associated with the particular online game, associating the participant information for each respective participant with the entry in the OGS database for the particular online game; and initiating the particular online game via the OGS involving each participant associated with the particular online game.
 2. The method of claim 1, wherein the game-related information is defined by an administrator of the particular online game.
 3. The method of claim 1, wherein the game-related information is generated automatically by the OGS based on pre-stored game-related information.
 4. The method of claim 1, wherein the one or more characteristics that define the particular online game are selected from the group comprising: game type, game name, game duration, physical event type, particular physical event, participant information, settings, scoring settings, game questions, game answers.
 5. The method of claim 1, wherein the electronic devices associated with participants are selected from the group comprising: mobile devices, cellular phones, smartphones, personal digital assistants (PDAs), computers, tablet computers.
 6. The method of claim 1, wherein the location information defining the particular geographic location associated with the particular online game comprises information defining a geographic boundary within which participants must be physically located to participate in the particular online game.
 7. The method of claim 1, wherein the location information defining the particular geographic location associated with the particular online game comprises one or more of the following: latitude and longitude coordinates, zip code information, neighborhood information, city information, state information, information relating to venues, information relating to arenas, information relating to restaurants, information relating to retail establishments, geographic area information, information defining a radii around a geographic location.
 8. The method of claim 1, wherein the participant location information comprises latitude and longitude coordinates.
 9. The method of claim 1, wherein the participant location information is received from one or more of the following: a wireless carrier, a global positioning system (GPS), a satellite triangulation system, a location-based service (LBS) provider, a social media check-in feature.
 10. The method of claim 1, wherein the physical event is selected from the group comprising: a sporting event, sporting events, an entertainment event, a television broadcast, an awards show, a political event, a newsworthy event.
 11. The method of claim 1, wherein the particular online game comprises one or more questions and answers that relate to the physical event happening in real-time.
 12. A method for conducting an online game via an Online Gaming System (OGS) involving a plurality of participants that participate in the online game via software operating on respective electronic devices of the plurality of participants, wherein the online game corresponds to a physical event happening in real-time, comprising the steps of: receiving an indication at the OGS during a particular online game for an in-game question corresponding to a particular physical event to be presented to participants of the particular online game as the particular online game is happening; retrieving question information corresponding to specifics of the in-game question; displaying the in-game question to the participants of the particular online game based on the question information; receiving answer information at the OGS from the participants of the particular online game indicating answer selections to the in-game question by the participants; storing the received answer information from each respective participant in an OGS database corresponding to each respective participant; receiving live event information corresponding to the particular physical event occurring in real-time; and generating a ranking of the participants of the particular online game based on the answer information and the live event information, and displaying the ranking to the participants during the particular online game.
 13. The method of claim 12, wherein the indication comprises satisfaction of one or more predefined rules associated with activities occurring with respect to the particular physical event.
 14. The method of claim 12, wherein the indication comprises a question submitted to the OGS by one of the participants of the particular online game.
 15. The method of claim 12, wherein the step of retrieving question information corresponding to specifics of the in-game question comprises retrieving predefined question information from the OGS database.
 16. The method of claim 12, wherein the step of retrieving question information corresponding to specifics of the in-game question comprises receiving question information from a participant of the particular online game.
 17. The method of claim 12, wherein the live event information comprises information corresponding to one or more activities occurring with respect to the particular physical event.
 18. The method of claim 12, wherein the electronic devices associated with participants are selected from the group comprising: mobile devices, cellular phones, smartphones, personal digital assistants (PDAs), computers, tablet computers.
 19. The method of claim 12, wherein the particular physical event is selected from the group comprising: a sporting event, sporting events, an entertainment event, a television broadcast, an awards show, a political event, a newsworthy event.
 20. The method of claim 12 wherein the particular online game comprises one or more questions and answers that relate to the particular physical event happening in real-time.
 21. The method of claim 12, further comprising the steps of: retrieving historical information relating to aspects associated with the particular physical event; generating predictive information corresponding to one or more answers associated with the in-game question; and displaying the predictive information in conjunction with the in-game question to the participants of the particular online game. 